
\documentclass{article}
% Paquetes que se van a usar
% --------------------------
\usepackage[a4paper,headheight=16pt,scale={0.7,0.8},hoffset=0.5cm]{geometry}
\usepackage{placeins}
\usepackage[utf8]{inputenc}
\usepackage{fancyhdr}
%\usepackage{amsfonts}
\usepackage{graphicx}
\usepackage{verbatim}
%\usepackage{array}
\usepackage{alltt}
\usepackage{moreverb}

% Configuracion de margenes
% -------------------------

\oddsidemargin   0pt
\evensidemargin  0pt
\textwidth       440pt
\textheight      660pt
\headheight      12pt
\topmargin       0pt
\headsep         20pt

\pagestyle{fancy}

\renewcommand{\contentsname}{Indice}

\rhead{\textsc{Programacion Orientada a Objetos}}
\lhead{ITBA}

\setlength{\parindent}{0pt}
\setlength{\parskip}{5pt}

\Huge{\title{\textbf{Programaci\'on orientada a Objetos \\TP Especial - "Trivia"}}}

\author{
	Tom\'as Alvarez\\
	Mar\'ia Belen Aguilera\\ 
	\\ \\ \\
	INSTITUTO TECNOLOGICO DE BUENOS AIRES}
	
	\date{\today}
	\makeindex
	
	
	% Empieza el documento.
	\begin{document}
	\newpage
	\maketitle
	\vspace*{2cm}
	\newpage
	
	\Large{
		\tableofcontents
		\newpage
		
		% Introduccion
		\section{Introducci\'on}
		
		
		\indent El desarrollo del tpe, consisti\'o en desarrollar el cl\'asico juego conocido como \textit{trivia} aplicando los conocimientos del paradigma orientado a objetos, con lenguaje de programaci\'on base: \textit{java}. 
		En lo que resta de este informe, se explican en detalle las caracteristicas de la implementaci\'on y desarrollo del
		juego, los desafios, problemas y soluciones  encontrados durante el transcurso de este trabajo pr\'actico.
		
		Se explica tambi\'en resumido el dise\~no de las jerarquias de clase utilizado, sus ventajas y desventajas a la hora
		de implementar el juego.
		
		% Desarrollo
		\section{Desarrollo Trivia}
		
		\indent La aplicaci\'on fue desarrollada mediante el conocido entorno de programacion IDE \textit{Eclipse} en conjunto con
		otra IDE conocida como \textit{netbeans}, la cual brinda un manejo muy flexible de la \textbf{API} de \textbf{Swing}, pues
		permite dise\~nar con absoluta libertad, la interfaz gr\'afica del programa, lo cual agiliza el desarrollo. Una desventaja de esto
		es que \textbf{netbeans} genera demasiado c\'odigo fuente, y en especial al ser la interfaz gr\'afica embedida en una sola clase, 
		hace que el archivo fuente sea muy engorroso, por contener muchisima cantidad de lineas de c\'odigo.
		
		El primer problema de dise\~no que surgi\'o, fue el de representar los distintos tipos de preguntas de la trivia, respetando
		y aprovechando el paradigma de objetos. La primera idea que tuvimos fue crear una clase abstracta \textbf{Question} con ciertos
		m\'etodos en com\'un para cualquier tipo especializado de pregunta, y luego crear una subclase concreta por cada tipo de pregunta
		existente en la trivia. Si bien \'esta es la soluci\'on que adopt\'o la mayoria de los grupos, nosotros obtamos por no separar
		las preguntas de opci\'on m\'ultiple de 1 o m\'as respuestas correctas, ya que el comportamiento de las mismas era muy similar,
		con lo cual no vimos la necesidad de producir dicho diferenciamiento de clases.
		
		A continuaci\'on el siguiente problema de dise\~no fue, la separaci\'on entre el back-end y el front-end. A modo de mantener
		independientes ambas partes, optamos por construir 3 paquetes (\textit{packages}), bien definidos que separan la aplicaci\'on en
		
		\begin{itemize}
		\item Interfaz Gr\'afica
		\item Base de datos
		\item Manejo de Archivos.
		\end{itemize}
		
		De esta forma, queda bien separada el front-end del back-end, y adem\'as se tiene un plus pues el nexo entre la base de datos que
		mantiene en memoria durante la ejecuci\'on del programa, todos los datos necesarios, y los datos en archivos se encuentran separados.
		De esta forma, si se alter\'a la forma en que se guarda o lee a disco los datos del juego, esto ser\'a oculto por parte de la base de
		datos, con lo cual no tendr\'a que sufrir variaciones severas en el c\'odigo.
		
		Por \'ultimo cabe destacar que para representar cada una de las Questions en la interfaz gr\'afica, se opt\'o por implementar un
		patr\'on de visita conocido como \textbf{Visitor Pattern}, que consiste en que cada pregunta implementa una interfaz llamada \textit{Visitable}, que contiene el m\'etodo accept, el cual recibe una instancia de un objeto que implementa una interfaz de nombre
		\textit{Visitor}, que lo que hace es simplemente delegar en esta instancia, las funciones de representaci\'on en pantalla, de modo
		tal que la el objeto pregunta no tenga que mezclar conceptos o componentes gr\'aficos, que poco tienen que ver con su comportamiento.

		\subsection{Nuevo Juego}
		Al comenzar un nuevo juego, se toma de la base de datos un listado de 10 preguntas, que son almacenados internamente en forma de una 
		LinkedList<Question>, que simplemente al ir el usuario respondiendo pregunta a pregunta, se itera sobre cada pregunta de la lista, 
		y en cada iteraci\'on dibujandola en pantalla. Por supuesto se valida que si para la dificultad elegida a la hora de comenzar un nuevo juego no se dispone de 10 preguntas, se le aviza al usuario y se le exige ir a la secci\'on edici\'on y agregar las preguntas que hagan falta. Cada vez que se contesta una pregunta, se valida si fue bien respondida y se acumula el puntaje en una objeto de la instancia GameUser que se encarga de mantener actualizados todos los datos relativos a la partida actual. Luego al finalizar, simplemente se extrae de esa instancia el nombre y puntaje del jugador y se lo despacha a un objeto de tipo HighScore que se encarga de agregarlo o no al top 10 seg\'un corresponda.
		
		\subsection{Editar Trivia}
		El n\'ucleo de la edic\'on consiste en una clase que extiende de jPanel, que internamente almacena una lista de preguntas de una misma categoria, y un indice de la pregunta seleccionada. Con lo cual permite identificar r\'apidamente al ejecutarse un evento de 
		edici\'on (Agregado, Editado o Borrado de una pregunta), el target sobre el cual se aplica dicha acci\'on. Luego como editar una pregunta en nuestro tp implica crear una nueva y pisarla con la anterior, aprovechamos eso y reutilizamos esos m\'etodos para el caso de agregar una nueva pregunta, con la excepci\'on de que no hab\'ia una pregunta original con la cual sobreescribirse.
		
		\subsection{HighScores}
		Los puntajes son mantenidos en una lista ordenada ascendentemente por objetos del tipo Score, que mantienen la informaci\'on del nombre de usuario y su puntaje asociado. Cuando la base de datos solicita un top 10, la instancia de tipo HighScore, se encarga de revertir el \'orden natural de estos elementos y devolver una lista con los puntajes descendentes. De esta forma se logra mostrarlos eficientemente. Para ello se tom\'o una simple tabla, y se volc\'o el contenido de dicha lista sobre la tabla.
		
		\section{Dificultades encontradas} 
		\indent 
		La mayor dificultad que se nos present\'o, fue el hecho de haber utilizado \textbf{netbeans} para desarrollar la GUI del programa.
		Esto se debi\'o a que todo el manejo de ventanas, eventos e interacci\'on con el usuario, debi\'o hacerse en una \'unica clase, lo cual adem\'as de ya de por si tener muchisimas lineas de c\'odigo fuente generadas por netbeans, agregar otra buena cantidad para implementar adecuadamente el front-end.
		
		Por otro lado, el hecho de haber implementado un patr\'on de visita para las preguntas en una clase separada a la dise\~nada por
		netbeans, gener\'o que no haya un acceso directo a las componentes gr\'aficas de cada pregunta externamente, lo cual dificult\'o seriamente la obtenci\'on de los datos que el usuario ingres\'o
		
		Por otro lado, la l\'ogica del juego no presento mayores complicaciones ya que no ten\'ia gran complejidad y fue resuelta desde un principio.
		
		Por \'ultimo, pero no menos importante, hubo dificultades a la hora de representar adecuadamente el listado de preguntas para poder
		ser editadas. Se sab\'ia de antemano que no ser\'ia aceptado como soluci\'on agrupar todas las preguntas del juego en una sola componente, pues en caso de existir cientos de preguntas, ser\'ia desprolijo.
		
		\section{Soluciones}
		En cuanto al c\'odigo generado por netbeans nada se pudo hacer, no le dimos tanta importancia al desarrollo eficiente del aspecto
		gr\'afico ya que no es lo que se eval\'ua. Aunque si se tendr\'a en cuenta de ahora en m\'as. En cuanto al patr\'on de visita, si bien no es lo m\'as \'optimo, se opt\'o por embedir dentro de los m\'etodos implementados de la interfaz \textit{Visitor} los handlers que controlen la interacci\'on con el usuario, y por cada cambio en las componentes gr\'aficas de una pregunta, almacenar
		inmediatamente la respuesta, de modo tal de poder validarla externamente, ya que si no, no era posible obtener la respuesta elegida por el usuario. 
		Una excepci\'on fueron las preguntas de texto simple y numericas, pues como su sencillez a la hora de representarse en la interfaz permit\'ia hacerlo con un simple \textit{Swing::JTextField}, entonces se iter\'o por todas las componentes del panel (Que en este caso iba a ser solo 1), y se extrajo de ella el texto que corresponde a la respuesta. Esto se hacia cada  vez que el usuario respond\'ia una pregunta y avanzaba a lo siguiente, pero para otros tipos de pregunta no fue posible.
		
		Para la representaci\'on del listado de preguntas, decidimos innovar e investigar un poco el uso de los \textbf{jPanel}. Entonces
		se nos ocurri\'o que simplemente podriamos crear un panel custom que herede los m\'etodos de un jPanel, y paginar las preguntas por nivel de dificultad y en grupos de a 10, proveyendo de un par de \textbf{JButton::Botones simples}, para avanzar o retroceder p\'aginas. La paginaci\'on no fue m\'as que la simulaci\'on de representar 10 preguntas diferentes sobre el panel, y al avanzar de p\'agina simplemente se mostraban las 10 siguientes preguntas que estaban almacenadas internamente por el panel custom. De \'esta forma qued\'o solucionado dicho problema. Aunque en caso de ser cientos de preguntas, navegar hasta la \'ultima p\'agina es tedioso.
		
		\section{Mejoras - Extensiones}
		
		Cabe destacar como mejora posible, el agregado de un sistema de navegaci\'on entre las p\'aginas del panel custom que permita avanzar de a m\'as de una p\'agina a la vez o incluso ir directamente hacia el n\'umero de p\'agina existente que deseemos. Otra mejora ser\'ia lograr que haya un nexo entre las acciones hechas por el usuario con las componentes gr\'aficas de cada pregunta y el resto de las componentes externas, de modo tal de lograr que solo al avanzar de pregunta, se almacene la respuesta, lo cual es m\'as l\'ogico y a la vez mucho m\'as eficiente.
		
		Como extensi\'on a este trabajo pr\'actico, pensamos que ser\'ia posible implementar un l\'imite de tiempo para responder una pregunta, asi como tambi\'en clasificar a las preguntas tambi\'en por categorias varias como lo hace el verdadero juego trivia. Aunque el desarrollo de una aplicaci\'on as\'i ser\'ia un poco m\'as complicado.
		
		\section{Conclusiones}
		Durante el desarrollo de la trivia, nos dimos cuenta que la reusabilidad de c\'odigo e este paradigma es muy \'util, y la herencia y el polimorfismo fueron factores claves que permieron desarrollar la aplicaci\'on m\'as sencillamete, que si hubiese tenido que desarrollarse en un lenguaje imperativo, pues habr\'ia que haber re definido incontable n\'umero de veces, distintas funciones para un mismo comportamiento. Tambi\'en podemos concluir que el hecho de que \textbf{java} no maneja punteros ni direcciones de memoria nos ahorr\'o seguramente muchisimos errores de programaci\'on y ejecuci\'on con los cuales hubiese retrasado notablemente el desarrollo de la misma. Cuando se detectaron errores, fueron corregidos muy rapidamente debido a esto.
		
		\newpage
		
		% Codigo fuente
		\section{C\'odigos fuentes}
		A continuaci\'on se presentan todos los c\'odigos fuentes implementados en cada una de las capas: \\
	}
	
	\subsection{Package:Datagraphics}
	
	% cliente.h
	\subsubsection{MainMenu.java}
	\small
	\verbatimtabinput[5]{../src/datagraphics/MainMenu.java}
	
	\subsubsection{EditPanel.java}
	\small
	\verbatimtabinput[5]{../src/datagraphics/EditPanel.java}
	
	% server.c
	\subsubsection{ModifiedFlowLayout.java}
	\small
	\verbatimtabinput[5]{../src/datagraphics/ModifiedFlowLayout.java}
	
	% stub.h
	\subsubsection{QuestionVisitor.java}
	\small
	\verbatimtabinput[5]{../src/datagraphics/QuestionVisitor.java}
	
	\subsubsection{Visitor.java}
	\small
	\verbatimtabinput[5]{../src/datagraphics/Visitor.java}
	
	
	\subsection{Package:DataProcess}
	
	
	\subsubsection{HighScoreDb.java}
	\small
	\verbatimtabinput[5]{../src/dataprocess/HighScoreDb.java}
	
	
	\subsubsection{Parser.java}
	\small
	\verbatimtabinput[5]{../src/dataprocess/Parser.java}
	
	\subsubsection{QuestionDb.java}
	\small
	\verbatimtabinput[5]{../src/dataprocess/QuestionsDb.java}
	
	\subsection{Package:Database}
	
	\subsubsection{Question.java}
	\small
	\verbatimtabinput[5]{../src/database/Question.java}
	
	\subsubsection{BooleanQuestion.java}
	\small
	\verbatimtabinput[5]{../src/database/BooleanQuestion.java}
	
	\subsubsection{SimpleQuestion.java}
	\small
	\verbatimtabinput[5]{../src/database/SimpleQuestion.java}
	
	\subsubsection{NumericQuestion.java}
	\small
	\verbatimtabinput[5]{../src/database/NumericQuestion.java}
	
	\subsubsection{MultipleQuestion.java}
	\small
	\verbatimtabinput[5]{../src/database/MultipleQuestion.java}
	
	\subsubsection{Score.java}
	\small
	\verbatimtabinput[5]{../src/database/Score.java}
	
	\subsubsection{GameUser.java}
	\small
	\verbatimtabinput[5]{../src/database/GameUser.java}
	
	\subsubsection{Category.java}
	\small
	\verbatimtabinput[5]{../src/database/Category.java}
	
	\subsubsection{Highscore.java}
	\small
	\verbatimtabinput[5]{../src/database/Highscore.java}
	
	\subsubsection{TriviaDbase.java}
	\small
	\verbatimtabinput[5]{../src/database/TriviaDbase.java}
	
	\subsubsection{Visitable.java}
	\small
	\verbatimtabinput[5]{../src/database/Visitable.java}
	
	\subsection{Package:TriviaException}
	
	\subsubsection{TriviaException.java}
	\small
	\verbatimtabinput[5]{../src/triviaException/TriviaException.java}
	
	\end{document}
	